Thanks! Do you have a bug report for Safari? I'd like to understand this bug better.

Hi @bramstein , I've reported my bug at https://www.apple.com/feedback/safari.html I hope I get some reply from that. I've tried reproducing this bug without webfontloader but I couldn't reproduct it yet.

Struggling with the same problem. Hopefully the fix gets accepted.

@bramstein I didn't get any response from my bug report at Apple, as stated below I cannot report this bug at webkit.

Note: Safari is not WebKit. Safari bugs should be reported to Apple.
https://webkit.org/reporting-bugs/

Do you have some other suggestion?

I think this is fixed in the technology preview because there we can use the native font loading API.

BTW I've got a report this fix doesn't work for Chrome on iOS (where this is fixed in Safari). Chrome on iOS doesn't use the Chrome rendering/javascript engine but the iOS system version of webkit.

Seems like this fix doesn't work for me (Sierra, safari 10.1.1) :(
Probably magic number(2412) is different under some conditions?

@AvaelKross I'm using the same version and it works, maybe you've got a retina display and use hidpi scaling? If you add console.info(a) to line 282 at src/core/fontwatchrunner.js you might find your "magic number" (please share it with us!).

Looks like '2410' is the magic number for me; retina 15" display. My situation: I'm using webfontloader for a text element on canvas, and on page reload, [?] boxes appear for a second and then replaced with the needed font. But different font size breaks text positioning on canvas (because [?] boxes are usually much wider than the original symbols). This is still an issue for me, BUT: Sometimes boxes weren't replaced with the needed font, and I guess this case should be fixed now with your code. So actually it may help someone.

My team has struggled with this quite a bit. It seems to me that some workaround (potentially this one, as it is also working for us) should be accepted into this library (with documented edge cases, or maybe an opt-in implementation). Especially in situations where load state accuracy is very important (e.g. drawing on a Canvas) this is a very problematic bug.

@bramstein any updates when this is going to be merged?

I encountered the same magic number issue when fixing something similar to this in #402. Perhaps the solution in #402 would also be a solution to this